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ABSTRACT 

In order to accomplish the full Vision for Space Exploration announced by former President 
George W. Bush in 2004, NASA will have to develop a new space transportation system and 
supporting infrastructure. The main portion of this supporting infrastructure will reside at the 
Kennedy Space Center (KSC) in Florida and will either be newly developed or a modification of 
existing vehicle processing and launch facilities, including Ground Support Equipment (GSE). 
This type of large-scale launch site development is unprecedented since the time of the Apollo 
Program. In order to accomplish this successfully within the limited budget and schedule 
constraints a combination of traditional and innovative strategies for Verification and Validation 
(V&V) have been developed. The core of these strategies consists of a building-block approach 
to V&V, starting with component V&V and ending with a comprehensive end-to-end validation 
test of the complete launch site, called a Ground Element Integration Test (GEIT). This paper 
will outline these strategies and provide the high level planning for meeting the challenges of 
implementing V&V on a large-scale development program. 

KEY WORDS: Systems, Elements, Subsystem, Integration Test, Ground Systems, Ground 
Support Equipment, Component, End Item, Test and Verification Requirements (TVR), 
Verification Requirements (VR) 

INTRODUCTION 

The Constellation Program (CxP) is responsible for planning and implementing those programs 
necessary to satisfy the requirements of national space exploration policies as delegated by the 
NASA Administrator. At the core of NASA’s future space exploration is the return to the moon, 
where NASA will build a sustainable long term human presence. As the space shuttle approaches 
retirement and the international Space Station nears completion. Constellation is building the 
next fleet of vehicles to take astronauts back to the moon. The fleet of vehicles will be launched 
at Kennedy Space Center (KSC) using Ground Systems. 

KSC Ground Operations Project is responsible for developing the launch site ground 
infrastructure to meet the Constellation mission. This infrastructure consists of the newly 
developed or modified physical support equipment, systems and facilities that are required to 
perform services at the launch, landing, and retrieval sites in support of the Constellation 
missions. Functions provided by the Ground Systems include receipt and inspection of flight 
hardware elements, software, cargo integration/deintegration; ground support equipment; 
spacecraft, launch vehicle; off-line processing of cargo; spacecraft and launch vehicle 
integration; integrated testing; reusable flight hardware refurbishment, launch; recovery; search 
and rescue; logistics; and command, control and communications in support of ground 
processing. 
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This type of large-scale launch site development is unprecedented since the time of the Apollo 
Program. In order to accomplish this successfully within the limited budget and schedule 
constraints a combination of traditional and innovative strategies for Verification and Validation 
(V&V) have been developed. The core of these strategies consists of a building-block approach 
to V&V, starting with component V&V and ending with a comprehensive end-to-end validation 
test of the complete launch site, called a Ground Element Integration Test (GEIT). The GEIT 
will led by the operations organization and supported by the design organization. This validation 
test consists of exercising people, processes and procedures using simulators and emulators in 
place of the launch vehicle to perform final validation of Ground Systems prior to the traditional 
time of performing this test. The traditional time would occur after the hardware has been turned 
over from the design organization to the operations organization. 
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Figure 1, Kennedy Space Center - Geographical 
Layout of Major Constellation Facilities 


25th Aerospace Testing Conference, October 2009 




Figure 2, Ground Systems Architecture 
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Ground Systems Architecture 


The Ground Systems architecture is composed of eight elements as shown in Figure 2. Each 
element in the architecture represents an asset or group of assets that provide functionality for the 
ground systems. Each of the elements includes facilities, infrastructure, facility systems, 
subsystems and support equipment hardware and software required to perform KSC ground 
operations for the purpose of receiving, processing, integrating, testing, servicing, launching, 
recovering, de-servicing and de-integrating CxP flight systems. 


KSC Engineering provides the element/subsystems with technical and systems expertise for 
understanding and implementing the requirements that have been allocated to them by the 
Ground Operations Project (GOP) System Requirements Document (SRD). The Element 
Requirements Document (ERD) decomposes these requirements down and allocates them to the 
subsystem level. The engineering organization will use these requirements to develop the 
necessary ground subsystems for the GOP in support of the Constellation Program. 


Requirement Closed Loop Process 

The requirements architecture is a closed loop process. The architecture begins with the program 
requirements and verification requirements and the decomposition of the requirements from the 
program down to the system. Next, the system decomposes these requirements down to the 
element and then decomposes these down to the subsystem. Finally, the requirements are then 
closed from the subsystem back up to the program creating a closed loop process. 

A relational database will be utilized to capture and integrate all of the design requirements for 
the Program and the Projects. Each requirement will have a corresponding verification 
requirement, which will define how the requirement will be verified. The Verification 
Requirement (VR) will include a verification method (test, demonstration, analysis or inspection) 
and a high level description of the verification and the associated success criteria. Each method 
of a VR will have a Test and Verification Requirement (TVR) to describe in detail how the 
requirement will be verified. These 3 “items” (requirements, VRs and TVRs) will be logically 
“linked” in the database to provide a traceable map of how all of the requirements will be 
satisfied. The results of each verification activity are the basis of closure for each requirement. 


Planning of Verification and Validation 

During development of Ground Systems, V&V plans are prepared to guide V&V 
implementation planning i.e., where, when and how will we accomplish V&V events and/or 
close the requirements. The strategy for verifying and validating this large-scale development 
project is contained in V&V plans. Currently there are over 12,000 verifications identified. These 
plans are critical to the success of completing the verifications as well as integrating the V&V 
activities to occur in parallel. V&V requires a teaming arrangement between 
designers/developers and operators. V&V traditionally occurred in serial, however for efficiency 
the new innovative approach now occurs in parallel, which further emphasizes the need for 
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strong teamwork between these two entities. Therefore, the VRs/TVRs will typically be 
performed and satisfied by both the design and development and operations engineering 
communities together as a team. This teaming arrangement will assist in validation activities 
occurring earlier with allowable risk. 

The V&V plans layout the strategy for integrating required hardware/software from other 
projects, hardware/software from vendors, newly designed hardware/software and heritage 
equipment into an element and perform each V&V activity as identified by the VRs and TVRs. 

Ground Subsystems V&V plans 

a. Provides the planning for subsystem requirements satisfaction by verification of 
the design 

b. Provides the planning for validation of the subsystems to show that each 
subsystem operates in its intended operational environment to the satisfaction of 
the user organization 

Design engineering will design, fabricate, assemble and integrate the hardware and 
software that make up a subsystem. Each subsystem will then be verified with the 
appropriate verification method(s) (test, demonstration, analysis and/or inspection). The 
verification of each subsystem will be complete once the design, functional and interface 
requirements have been met. The subsystems V&V plans define the development test and 
evaluation verification activities that ensure the subsystem meets its design and 
performance requirements and the operational test and evaluation validation process that 
ensures operational requirements are met. 

Ground Elements V&V plans 

a. Provides the planning for V&V of facilities, facility systems, and GSE for ground 
processing of the flight vehicle. Includes planning for system and element 
requirements satisfaction. Also includes Statement of Work and Heritage 
Hardware planning. Includes narrative descriptions of V&V tests/demonstrations 

Once all of the subsystems within an element have been verified, all of these subsystems 
(facility infrastructure, facility systems and support equipment) will be integrated 
together and verified as an element. This verification will consist of ensuring that all 
subsystems within the element properly operate/function together. The element-to- 
element interface requirements will be verified using both sides of the interface. The 
verification of each element will be complete once the functional, interface, and design 
requirements have been met for that element. The ground element V&V plans define 
development test and evaluation verification activities that ensure ground elements meet 
its design and performance requirements. The plans also define the operational test and 
evaluation validation process that ensures operational requirements are met from the end 
item level through the development of ground elements level including software, GSE 
and facility infrastructure. 
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Ground System 


After each of the ground elements has been verified, a Ground Element Integration Test 
(GEIT) or set of tests will be performed. These testing activities will consist of operating 
the ground elements in concert with one another in order to confirm the interoperability 
and functionality between the elements. Once Ground Systems validation (GEIT) is 
complete, Ground Systems will be ready to interface with flight hardware. 


Ground Element Integration Test Details 

GEIT is an integration test between multiple GOP ground elements in order to validate Ground 
Systems prior to processing the first flight test vehicle. GEIT will consist of operating the 
ground elements in concert with one another in order to confirm the interoperability and 
functionality between the ground elements. These tests will occur after the ground systems 
have been verified. These tests are used to assure that the ground elements can work together as 
a unified ground system and support flight processing and launch operations. Refer to Figure 3 
for the diagram showing the integrated interfaces of elements and their subsystems. Note: 
Simulators and emulators will be used in place of the vehicle for actual testing. 
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Figure 3, GEIT Integrated Diagram 
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The primary goals of the GEIT are as follows: 

(a) to validate Ground Systems design by demonstrating the interoperability, 
functionality, and stability of the ground elements, subsystems and components as 
an integrated ground system before they are used to process and launch a 
Constellation Program (CxP) launch vehicle for the first time 

(b) to validate critical ground processing activities and procedures in the operational 
environment prior to their first-time execution with flight hardware 

(c) to validate ground test team readiness to support flight vehicle processing and 
launch operations 


Ground Element Integration Test Configurations 

Based upon the location of when multiple ground element testing will occur there are 
three possible candidate configurations and general test configurations for GEIT testing 
that have been identified: 


GEIT MPPF Test Configuration #1 



GEIT TEST #1 Test Objective -Validate subsystem compatibility by activating/operating the 
Space Craft Processing Element power/fluids/data subsystems through the umbilicals to 
flight simulators using Command Control and Communications Element in the Multi- 
Payload Processing Facility. 
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GEIT VAB Test Configuration #2 



GEIT TEST #2 Primary Test Objective -Validate subsystem compatibility by 
activating/operating all subsystems through the umbilicals to flight simulators at all required 
locations using Command Control and Communications Element in the Vehicle Assembly 
Building. 


GEIT Launch Pad Test Configuration #3 



GEIT TEST #3 Primary Test Objective -Validate subsystem compatibility by 
activating/operating all subsystems through the umbilicals to flight simulators at all required 
locations using Command Control and Communications Element at the launch pad. 
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GEIT Test#1 Multi Payload Processing Facility (MPPF) Summary 


The GEIT Test #1 will include integrated testing necessary to validate the elements and 
subsystems in a “day of test” configuration. The objectives will be to configure the 
Spacecraft Processing Element (SPE) provided subsystem along with the Command 
Control Communication Element (CCCE) hardware/software and a set of a test 
equipment simulating the vehicle to perform a set of activities that involve commanding 
the vehicle, providing power and commodity servicing using remotely controlled 
manually activated systems retrieving, sending and storing data. (Reference Figure 3 for 
GEIT integrated diagram). Real-time operational data will be captured locally in the 
Orion Launch Control System. 


GEIT MPPF Test #1 Implementation 

The overarching goal is to ensure that the elements and subsystems operate as intended in 
the operational environment as a whole to affect final validation. The nominal hazardous 
operations will be performed in serial rather than parallel. Therefore only one simulated 
hazardous operation will be performed during GEIT Test #1. The GO 2 subsystem was 
chosen to support GEIT Test #1, mainly because it interfaces with auxiliary subsystems, 
GHe, GN 2 , R134A refrigerant and a Launch Control System set. Refer to Figure 4 for test 
configuration. 

Each subsystem will be configured in a sequence representative of the nominal 
activation. Procedures, which are run by operational engineers, will be used to configure 
and power up subsystems or integrated into GEIT procedures. This will help validate the 
ground test team readiness and ground procedures used during flight vehicle processing. 

The GSE will be remotely operated to validate all redundant commands, safing controls, 
software operational programs, and monitoring. This system test will effectively 
characterize the interfaces between the subsystems. The outcome will ensure assets from 
both the CCCE and the SPE elements can work together as an integrated ground system. 
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GEIT MPPF Test Configuration #1 
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FIGURE 4, GEIT TEST #1 SETUP 
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GEIT TEST #2 In The Vehicle Assembly Building (VAB) Summary 


The GEIT Test #2 will be performed in the VAB. The GEIT Test #2 will include 
integrated testing necessary to validate the ground elements and subsystems in a “day of 
test/launch” configuration. The primary objective will be to activate the Mobile Launcher 
Element (MLE), Vertical Integration Element (VIE) and the CCCE in order to perform a 
set of activities that involve commanding, providing power and commodity servicing 
between the elements to ensure all interfaces and functionality between each element are 
validated for all subsystems. Each subsystem will activate in the sequence that would be 
representative of the nominal subsystem. Procedures, which are run by operational 
engineers, will be used to configure and power up subsystems. This will validate the 
ground test team readiness and ground procedures used during flight vehicle processing 
and launch operations. 

GEIT TEST #2 In The VAB Implementation 

Following verification, the MLE and VIE would be configured for GEIT as shown in 
Figure 5. The Mobile Launcher will be located in the VAB high bay. All connections will 
be established between the MLE and the VIE. The GSE (flight emulators, simulators and 
load banks) will be appropriately located in the required locations within the ML tower. 

The umbilical arms will be attached in the stowed position vertically up against the ML 
tower. The flight simulated umbilical plates will be attached to the ground umbilical 
plates and cables and fluid lines will be attached from the flight plates to the simulators, 
emulators and load banks. 

Once the setup for the integrated test scenario is complete, all subsystems will be 
activated and ready to perform the GEIT Test #2 in order to validate subsystem 
compatibility given max power, gas flow, access configuration, electromagnetic 
compatibility and RF environment. 
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GEIT VAB Test Configuration #2 
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Figure 5, GEIT Test #2 Setup 
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Figure 6, Ground Umbilical Plates Attached to Flight Umbilical Plates 



Figure 7, Emulators/Simulators Attached to Flight Umbilical Plates 
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GEIT Test #3 At The Launch Pad Summary 

The Launch Pad Element (LPE) GEIT will include integrated testing necessary to 
validate the elements and subsystems in a “day of test/launch” configuration. The 
objectives will be to configure the MLE, LPE and the CCCE to perform a set of launch 
preparation activities that involve commanding, providing power and commodity 
servicing between the elements to ensure all interfaces and functionality between each 
element are validated for all subsystems. The overarching goal is to ensure the elements 
and subsystems operate as intended in the operational environment as a whole to affect 
final Ground System validation. Each subsystem will be configured in a sequence 
representative of the nominal activation. Procedures, run by operational engineers, will 
be used to configure and power up subsystems. This will validate the ground test team 
readiness and ground procedures used during flight vehicle processing and launch 
operations. 


GEIT Test #3 Launch Pad Implementation 

The Mobile Launcher will roll out to the launch pad with umbilical arms attached to the 
tower and simulators and emulators remaining in the Mobile Launch Tower during 
transit. Following verification, the Mobile Launcher and pad would be configured for 
GEIT as shown in Figure 8. All subsystems will be configured and activated for GEIT 
Test #3: 

Once the setup for the integrated test scenario is complete, perform the GEIT Test #3 to 
validate subsystem compatibility given max power, gas flow, access configuration, 
electromagnetic capability and RF environment. 
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GEIT Launch Pad Test Configuration #3 
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Figure 8, GEIT Test Setup #3 
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Turnover and Ready To Support Flight Testing 

As part of GEIT, the operational community will develop test procedures and run the operational 
tests with the design engineer’s assistance in trouble shooting and modifying design if required. 
The operational community will be able to train the personnel while validating test procedures. 
At the completion of the final GEIT, Ground Systems will be ready for turnover to the 
operational organization. By post turnover or the Operational Readiness Date (ORD) the 
operational community is ready to process the launch vehicle. 

Traditional method would have meant post turnover (ORD) would still need operational 
procedures to be developed, process to be exercised and the personnel to be trained. For example 
an Operational Readiness Test would still need to be performed. If there were any design 
modifications required due to problems during testing the cost impact would be significant 
because the item tested would have already been turned over and under formal configuration. 
Because of the innovative approach of combining the operational tests with GEIT, the schedule 
duration would be shortened by approximately thirty days. 
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Traditional Approach 

Traditionally in previous programs, Ground Operations performed all V&V activities in a serial 
manner utilizing a step function. Each step required verification then validation before 
proceeding to the next level. The verification and validation process had to be repeated through 
each step of the approach beginning with components, leading to subsystems, followed by 
elements, ultimately ending with ground system operational readiness. Once all V&V 
requirements were met, design engineering would then turn over the system to operations 
engineering for operational readiness tests and reviews prior to declaring Ground Systems 
operational ready to process flight hardware. 


Utilizing this traditional step function method of incremental build creates overlap and 
duplication of test activities. Since these activities were performed in serial the duration extended 
months longer than the current innovative approach being adopted by Ground Systems for the 
Constellation Program. 
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Innovative Approach 

The complexity of developing the Constellation Ground Systems is not only the management of 
intertwining thousands of components contained within over seventy subsystems that span across 
multiple elements, but it is also inclusive of the management of the people and integration of the 
multiple designs, operational and institutional organizations. In order to orchestrate this complex, 
multi-organizational project the need for strategic planning and innovative approaches is crucial 
to our success. 

The ability to bring the operations organization online during verification allows for validation to 
be combined with verification. Subsystem and element V&V will be performed in parallel 
allowing the V&V requirements to be satisfied by both the design/development and operations 
engineering communities together as a team. 

Instituting a streamlined process by performing GEIT satisfied the integrated element to element 
V&V requirements by testing end to end interface functionality and interoperability between 
elements having all the elements up and running with operational processes and procedures. The 
GEIT also satisfies the need to perform the Operational Readiness Test which is required by the 
operations community because it exercises the personnel, processes and procedures. Inclusion of 
the Operational Readiness Test satisfied within GEIT eliminates the need to perform additional 
operational readiness testing after the Operational Readiness Date, thereby eliminating that major 
task which typically occurred after the Operational Readiness Date. 

Innovative 
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Reducing the amount of serial testing assumes the risk of finding anomalies near the end of the 
development schedule. However, this is an acceptable risk given the strict constraints on the 
schedule and budget put on the Constellation Program. 

The innovative, strategic approach minimizes budget and schedule by performing the GEIT 
streamline operation of linear testing by combining the Operational Readiness Test with GEIT. 
This method will allow GOP to satisfy the program’s allocated requirements and prove to the 
CxP that GOP is ready to support nominal ground operation processing. 
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Summary & Conclusion 


Developing a new space transportation system and supporting infrastructure presents a unique set 
of complicated challenges. This type of all-inclusive launch site development is unprecedented 
since the time of Apollo. Utilizing a combination of traditional and innovative strategies for 
V&V will fulfill the numerous, complex challenges of implementing the launch site ground 
infrastructure. The core of these strategies consists of an innovative, streamlined approach to 
V&V. Bringing the operations organization online during subsystem and element verification 
allows for some of the validation to be combined with verification, which dramatically reduces 
time and cost issues. Furthermore, comprehensive end-to-end validation test (GEIT) of the 
complete launch site, satisfies the integrated element to element V&V. Finally, having the 
ability during GEIT to exercise not only hardware but the personnel, processes and procedures 
thereby eliminates the need for additional Operational Readiness Testing. This comprehensive, 
reorganized course of action allows the Ground Operations Project to progress and stay within 
the limited budget and schedule constraints for developing launch site ground infrastructure for 
the Constellation Program. 

It is imperative that during the implementation of V&V, not only are the multi-organizations 
tightly coupled, but these organizations are able to orchestrate the highly integrated components, 
subsystems and elements to demonstrate end-to-end interoperability of Ground Systems. 

This paper outlined strategies and provided high level planning for meeting the challenges to 
ensure success that the GOP is ready to support nominal ground operations processing for the 
Constellation Program. 
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L02 Servicing Subsystem breakout example 
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L02 Servicing Subsystem breakout example 
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L02 Servicing Subsystem breakout example 
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GEIT : An integration test between multiple GOP ground elements in 
order to validate Ground Systems prior to processing the first 
flight test vehicle. 

■ These tests will occur after the Ground Elements has been verified. 


The primary objectives of the GEIT are: 


> To validate Ground Systems design by demonstrating the interoperability, 
functionality, and stability of the ground elements, subsystems, and 
components as an integrated ground system before they are used to 
process and launch a Constellation Program (CxP) launch vehicle for the 
first time. 

> To validate critical ground processing activities and procedures in the 
operational environment prior to their first-time execution with flight 
hardware. 

> To validate Ground Test Team readiness to support flight vehicle 
processing and launch operations. 


8 





GEIT Elements 



CONSTELLATION 


Constellation Program 


Constellation 

Architecture 


Ground Ops Project 


Orion 


EVA 


Ares l/V 


Altair 

System 


System 


System 


System 


Ground 

Systems 


Mission 

Systems 


Ground Systems Elements 


GEIT Elements to be Tested 


Spacecraft 

Processing 

Element 


Command, 
Control & 
Comm 
Element j 


Vertical 

Integration 

Element 


Mobile 

Launch 

Element 



Subsystem 1 
Subsystem 2 
Subsystem 3 
Subsystem 4 

Subsystem 76 


Launch Pad 
Element 


Recovery & 
Retrieval 
Element 


Solid Rocket 
Processing 
Element 


Operations 

Support 

Element 


9 






















CONSTELLATION SYSTEMS 



Subsystems/Elements Integrated Diagram 
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GEIT Test #1 at MPPF 
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•The nominal hazardous operations will be performed in 
serial rather than parallel. Therefore only one hazardous 
operation will be performed during GEIT Test #1 . 

•The G02 subsystem was chosen to support GEIT Test 
#1 , because it interfaces with auxiliary subsystems, GHe, 
GN2, R134A refrigerant, and a MPPF LCS set. 
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GEIT Test #2 at VAB 
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•No vehicle present 

• Simulators/Emulators/Load 
Banks all on ML Tower 



L 


GEIT VAB Test Configuration #2 
(3/11-29/13) 



System flight vehicle 
simulators/emulators/ 
load banks located at 
various levels 
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GEIT Test #2 at VAB 


in 

l 

in 

> 

in 

z 

0 

h 

< 

J 

i 

in 

z 

0 

u 


Tilt Up Umbilical Arm 



GSE cables / flex hoses 
various system “flight 
emulators” 


to 


Flight Umbilical 
Plate Interface 


Ground Umbilical 
Carrier Plate 



GSE Test Configuration 


13 




1 


in 

t 

B 

in 

> 

in 

z 

0 

h 

< 

J 

* 

in 

z 

0 

u 



GEIT Test #3 at Pad 
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• No vehicle present 

• Unable to perform wet 
dress for LOX/LH2 

• Unable to perform T-0 
disconnect 
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System flight vehicle 
simulators/emulators/load 
banks located at various levels 


GEIT Launch Pad 
Test Configuration #3 
(7/5/13-8/1/13) 
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Traditional 


Traditional Approach 



CONSTELLATION 


Subsystems 

Verifications 


Subsystems 

Validations 



Integrated 

Element 

Validations 


/ ord\ 


Operational 

Readiness 

Test 

Operational 
Readiness 
Reviews | 


> Ground Operations performed all V&V activities in a serial manner utilizing a step function. 

> Each step required verification then validation before proceeding to the next level. 

> The verification and validation process had to be repeated through each step of the 
approach beginning with components, leading to subsystems, followed by elements, 
ultimately ending with ground system operational readiness. 

■ ■■■■'-■ - ■ ■ ■■■ ■ ■■■■■ ■ . - - - - _J 

15 








« 




Innovative Approach 
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> Subsystem and element V&V are now performed in parallel allowing the V&V 
requirements to be satisfied by both the design/development and operations 
engineering communities together as a team. 

> Performing GEIT satisfied the integrated element to element V&V requirements by 
testing end to end interface functionality and interoperability between elements 

> The GEIT also satisfies the need to perform the Operational Readiness Test which is 
required by the operations community because it exercises the personnel, processes 
and procedures 
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Conclusion 
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> Bringing the operations organization online during subsystem and element 
verification allows for some of the validation to be combined with verification, which 
dramatically reduces time and cost issues. 

> Furthermore, comprehensive end-to-end validation test (GEIT) of the complete 
launch site, satisfies the integrated element to element V&V. 

> Finally, having the ability during GEIT to exercise not only hardware but the 
personnel, processes and procedures thereby eliminates the need for the 
Operational Readiness Test. 

> Not only are the multi-organizations tightly coupled, but these organizations are able 
to orchestrate the highly integrated components, subsystems and elements to 
demonstrate end-to-end interoperability of Ground Systems. 

> This comprehensive, reorganized course of action allows the Ground Operations 
Project to progress and stay within the limited budget and schedule constraints. 
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